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(54) Method and control system for controlling a plurality of robots 



(57) A system for controlling a plurality of robots and 
a method for controlling said system. Said system com- 
prises a plurality of controllers, each having an associ- 
ated motion system adapted to control attached robots, 
with each motion controller being able to receive motion 
instructions from at least one motion instruction source 
and at least one of said motion instruction sources being 



a control program, as well as a computer network over 
which said controllers communicate. In this way, the in- 
vention can be applied to solve problems which are 
commonly encountered in coordination activities such 
as load sharing, mating of parts while processing, fix- 
tureless transfer, teaching, manual motion of coordinat- 
ed operations, and time coordinated motion. 
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Description 

[0001] The present invention relates to a system for 
controlling a plurality of robots and a method for control- 
ling a system of a plurality of robots, the system com- 5 
prising a plurality of robot controllers, each with an as- 
sociated motion system adapted to control attached ro- 
bots, with each controller being able to receive motion 
instructions from at least one motion instruction source 
the controllers being connected with each other by a io 
computer communication network. 
[0002] By using a single controller for multiple robot 
coordination the "locality of coordinated control" is lim- 
ited to the number of robots controllable by that control- 
ler. For example, a typical coordination problem with >5 
multiple robots is to transfer a part between robots with- 
out using intermediate fixtures. A controller capable of 
controlling only four robots would permit coordinated 
handoff of parts between the four robots, but would re- 
quire a conventional fixture station or other solution 20 
when handing the part to a fifth robot controlled by a 
separate controller. On the other hand, a plurality of ro- 
bots each having its own controller, with all controllers 
connected by a communication line, does not have this 
locality limitation. 25 
[0003] The US 6,330,493 B1 shows a control system 
applied to several robot controllers connected by a com- 
munication line. This solution solves the specific prob- 
lem of limitation of robots being able to be coordinated 
by one controller, but it solves this problem only with 30 
marginal precision, and leaves other coordination prob- 
lems unsolved. 

[0004] Such coordination problems of several robots 
include: 

35 

Load sharing - The ability for two or more robotic 
machines to carry the same part or load requires 
the robots to keep a fixed spatial relationship while 
carrying the load. This particular coordination prob- 
lem is also solved in the prior art, but is introduced 40 
here as background to the other coordination prob- 
lems. 

Parts mating while processing - In addition to the 
requirement for a fixed spatial relationship among 45 
two or more robots, one or more additional robots 
must perform a process relative to the assembly, 
and one or more robots may enter and leave the 
assembly during processing (cf . further explanation 
below). 50 

Fixtureless transfer - One or more robots may need 
to rendezvous with one or more other robots while 
all of them are in continuous motion. 

55 

- Manual motion of coordinated operations - When a 
production line is stopped because of an error, with 
two or more robots carrying the same part or holding 



multiple mating parts, it may be necessary to man- 
ually move the multiple robots in coordination to 
prevent breaking or dropping the part. 

- Teaching of coordinated operations - In activities 
where a fixed spatial relationship is maintained, 
such as part mating or load sharing, it is useful if the 
various robots need to be taught only one or a few 
grasping positions relative to the parts. Each robot 
should not have to be taught the entire part path, 
and if the part path is changed, only one of the ro- 
bots should have to be re-taught to effect the path 
change. 

Time coordinated motion - Multiple robots may need 
to carry out Identical or mirrored processes in lock 
step timing with each other. There is no spatial re- 
lationship among the robots, but time alignment of 
their motions may be required. 

[0005] The most complex of the above problems is si- 
multaneous parts mating while processing. An example 
is the process of joining two small parts to a large part 
by arc welding using three robots without stationary fix- 
tures: Robot 1 carries the large part. Robot 2 carries the 
two small parts, one at a time, and Robot 3 carries the 
arc-welding torch and performs the welding process. 
Such a process normally requires the large part to move 
simultaneously and time coordinated with the welding 
robot so that the welding robot can reach the entire part 
and the molten seams maintain a nearly horizontal ori- 
entation. This in turn requires spatial coordination of the 
motions of Robots 1 , 2 and 3. Robot 2 must maintain a 
fixed position relative to Robot 1 , so that the small part 
remains properly mated with the large part, and Robot 
3 must carry out its welding process relative to the mov- 
ing parts held by Robots 1 and 2. 
[0006] As the weld proceeds, it is possible for Robot 
2 to release its grasp of the small part, because the part 
has been tacked into position. Robot 2 can leave the 
assembly while the assembly motion is in progress and 
go fetch the second small part. Robot 2 returns with the 
second small part to rendezvous with the assembly. Ro- 
bot 3 welds the second small part to the large part, again 
while ail three robots move with spatial coordination. 
[0007] The interesting features of said process be- 
sides the changing spatial relationships of the three ro- 
bots are the following: 

I. Robot 2 both leaves and joins the assembly while 
the latter may be in motion and changes from spa- 
tially coordinated motion to independent motion, or 
vice-versa, while the assembly may be in motion. 

II. Typically, a portion of the welded seams are de- 
fined with respect to the small parts. For those por- 
tions, the arc welding robot is moving relative to the 
small parts, which at the same time must maintain 
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a fixed position with respect to the large part. This 
is referred to as a "chain of spatial dependencies". 

[0008] In the aforementioned US 6,330,493 B1 a 
"synchronous cooperative operation" is defined. This 
operation occurs between a master and one or more 
slave robots. The definition of which robot is master and 
which are slaves is kept in software-based "link pat- 
terns". Link patterns change only between program 
sets. Thus, to change a given robot from coordinated 
operation with another robot to independent operation 
requires starting a new program in a sequence, and con- 
tinuous motion between programs is not provided for. 
Thus, ft is not possible to have a robot change from slave 
to independent operation and back to slave again all 
while the master remains in motion, as required in point 
1 above. More generally, rendezvous and departure of 
one robot with another in motion is not possible with a 
single "synchronous cooperative operation" as defined 
in US 6,330,493 or even multiple such operations. 
[0009] Fixtureless transfer of parts also requires a 
rendezvous capability and a change from coordinated 
to independent operation as described above. The prior 
art is also not suitable for such coordination activity, ex- 
cept where all robots are controlled by a single control- 
ler, which in turn limits the locality of coordinated control. 
[001 0] As noted above, in the related art the designa- 
tion of master and slave robots is kept in link patterns, 
which can only be changed by changing programs. 
Thus, it is not possible for a robot to be both a master 
and a slave in the same program, and it is not possible 
for a robot to be both master and slave simultaneously. 
Thus, there is no way to implement the "chain of spatial 
dependencies" required by point 2 above using the re- 
lated art. 

[0011] An example of coordination activities listed 
above is load sharing. Once the coordinated activity be- 
gins, there is no relative motion between the grippers of 
the various robots carrying the part, so any method that 
can provide for a fixed spatial relationship during pro- 
grammed motion may successfully carry out this activity 
with some level of precision. However, if production op- 
eration is stopped in the middle of such an activity, and 
it is required that the shared or mated assembly be 
moved out of the way, it must be possible to have a man- 
ual motion capability to move the shared assembly. 
[0012] Using load sharing as a simple example, one 
can examine the activity of teaching a coordinated op- 
eration. Assume a heavy part that requires three or more 
robots to carry the part. One possibility is to provide a 
lightweight mockup, so that teaching can be carried out 
with one robot at a time. One would like to teach the path 
of this part in a conventional way, e.g. by simply using 
the standard manual motion and teaching system of the 
first robot to guide the robot carrying the part along the 
required path, recording required path positions and 
control program instructions along the way. Such a tech- 
nique is provided for in most industrial robot systems 



today. 

[0013] A first step in this technique is to determine a 
reference frame on the part that can be used as a basis 
for jogging the part held by the robot. With most indus- 

s trial robots manufactured today, it is possible to teach a 
reference frame, known as the Tool Center Point (TCP) 
at a fixed position relative to the tooling mounting plate 
of the robot. In this case, the common reference frame 
on the part becomes the TCP for the first robot. The 

10 taught path of the part using the first robot is actually the 
path of that part reference frame. By teaching a TCP for 
the first robot, and two grasp points for the other two 
robots relative to the common part reference frame 
(TCP), the three robots can remain locked together both 

is during manual motion and during playback of the de- 
sired part path. 

[0014] Once the program and its associated taught 
positions and other data are prepared, the remaining 
two robots must be instructed on how to share the load. 

20 ideally, this should be done by simply teaching a grasp 
point for each of the two remaining robots at two points 
on the part. It is desirable to do this by teaching these 
grasp positions relative to the common reference frame 
on the part, i.e. the TCP of the first robot. In this way, 

25 regardless of the path of the part carried by the first ro- 
bot, if the other two robots know the position on the ref- 
erence frame, they need only to move to their respective 
grasp positions relative to that reference frame to grasp 
the part, and remain at their respective grasp positions 

30 relative to the reference frame to carry the part. 

[001 5] The technique is particularly useful during the 
tedious teaching process, when the taught path of the 
part can change often. Once the actual heavy part re- 
places the lightweight substitute part, it is critical that the 

35 two "helper" robots keep their relative grasp position 
during any final touch-up, re-teaching or manual motion 
of the path carried out by the first robot. 
[0016] The two primary requirements of the above 
technique are the ability for coordinated manual motion 

40 and the ability to teach positions for one robot relative 
to reference frames defined on another robot. Neither 
of these capabilities are provided in the prior art, except 
where the robots involved are controlled by a common 
controller. 

45 [0017] Time coordinated motion between two or more 
robots is a useful form of coordination where the robots 
do not have a direct spatial relationship, but must run 
identical motions in separate programs in lock step. For 
example, when each of two robots follows an identical 

so or mirrored path on a common part or two parts and the 
parts are mounted on a movable table, then the two ro- 
bots must remain together during execution, so that they 
keep the same relative position to the moving table. This 
is quite common in the automotive industry where left- 

55 and right-handed versions of a part are to be assembled 
and welded simultaneously. It is common that the parts 
are large and must be carried on a single large table 
positioner to rotate them while the two robots weld the 
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separate left- and right-handed parts. If the two robot 
control programs do not run in lock step, then it is pos- 
sible that the table would move the part out of reach of 
one robot, while the other is properly welding, or that a 
molten seam on one part would deviate from its intended s 
run on that part while the other is correctly welded. Solv- 
ing this problem by starting and stopping one robot to 
keep in step with the other is not possible in arc welding 
or other processes where the seam must be welded 
continuously. 10 
[0018] The above problem can be generalized to 
more than two robots in cases where many parts are 
carried on a common movable table or rotating axis, 
such that there is one processing robot for each part, 
and all robots must be coordinated in time to match rel- '5 
ative position to the common table or axis. In this general 
form, each robot must maintain a spatial relationship 
with the table (but not necessarily with the other robots), 
and the motions generated by the robot control pro- 
grams must remain coordinated in time with each other. 20 
[0019] Coordination in time of the motion of two or 
more robots means that the motions must begin and end 
together, and in general follow the same relative accel- 
eration and speed profile on each robot. Since the mo- 
tion distances might be slightly different for each robot, 25 
this is not a straight forward task, and the ability to syn- 
chronize motion in this way between robots controlled 
by separate controllers has not been implemented in the 
prior art. 

[0020] Another important issue common to all of the 30 
above types of coordinated motion is accuracy. When 
two or more robots carry multiple mating parts, or a com- 
mon part, it is undesirable to have any relative motion 
between the robots, as this could cause stress in the 
part or misalignment of the mating parts. In the prior art, 35 
independent controllers, connected only by a communi- 
cation line, may have misalignment between their inter- 
nal clocks, and the output of their respective motion sys- 
tems to their respective servo systems may not occur at 
exactly the same time. Such an error in registration at 40 
update times can cause stress or misalignment. For ex- 
ample, if the interpolation interval of the controllers is 16 
milliseconds, and the interpolation clocks of two control- 
lers are misaligned by nearly a full clock cycle, then an 
output from each interpolator will be used by the respec- 45 
tive servo systems as much as 1 6 milliseconds apart. 
At a speed of 1 meter per second this induces 16 mil- 
limeters of misalignment between the robotic machines. 
An error of this magnitude is not tolerable in applications 
such as those found in the automotive industry, for ex- so 
ample, where robot accuracies near 1 millimeter are ex- 
pected. 

[0021] In the US 6,330,493 B1 , where multiple robots 
are controlled by different controllers; applications are 
limited to low speed or applications where misregistra- 55 
tion between coordinating robotic machines is permit- 
ted. 

[0022] Several methods and standards exist for align- 



ing clocks between systems. Some methods provide for 
computer clock alignment using standard communica- 
tion lines such as Ethernet. For example, the new IEEE 
1588 standard provides this capability. Various publica- 
tions, such as Horst F. Wedde and Wolfgang Freund, 
Harmonious internal clock synchronization, in EUROM- 
ICRO Workshop on Real-Time-Systems 2000 
(ERST00), IEEE Computer Society Press, p. 175-182, 
also suggest similar methods. However, the problem in 
a typical robot controller is that there are several clocks 
which ail must be aligned for motion registration be- 
tween two or more controllers. For example, a hardware 
clock is typically used in servo loop hardware to control 
the closure rate of digital servo loops. There may also 
exist a subinterpolator that runs at a multiple of the servo 
loop clock interval and an interpolator that runs at an- 
other multiple of the subinterpolator interval. These in- 
tervals usually must remain fixed and precise. 
[0023] The published algorithms and methods, such 
as IEEE 1586, discuss how to align the execution of 
computer tasks or algorithms among systems connect- 
ed by a communication line, but this does nothing to 
align the actual hardware clocks of the individual sys- 
tems connected by the communication line. So for ex- 
ample, interpolators might be aligned with each other by 
these methods, but subinterpolators might be based on 
the individual hardware clocks, and these would not be 
aligned. In addition to the methods suggested by the 
published standards and algorithms, additional meth- 
ods are needed to align ALL clocks including hardware 
clocks. 

[0024] In summary, following is a list of requirements 
for coordinated activities between robots controlled by 
separate controllers that are not solved in the prior art 
and therefore form an objective for the present inven- 
tion: 

rendezvous and departure of one robot onto a part 
or assembly held by one or more other robots in or- 
der to support mating parts with assemblies and to 
support fixtureless transfer of parts between robots; 

manual motion of parts or assemblies held by mul- 
tiple robots in order to support maintenance and 
teaching; 

- teaching positions for one robot relative to a refer- 
ence frame on another robot in order to make coor- 
dinated applications easier to teach and more reli- 
able; 

time coordination of similar motions on different ro- 
bots in order to permit them to follow auxiliary axes 
simultaneously and to support repeatable process 
relative motions; and 

clock alignment among robot controllers in order to 
make motion registration between robots accurate. 
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[0025] It should be understood that all the above fea- 
tures in the prior art only exist on single commercially 
available robot controllers capable of controlling multi- 
ple robots from the single controller. When individual 
controllers are used for each robot, and the controllers 
communicate by a standard communication line such 
as Ethernet, these features do not exist. 
[0026] There is a need for a multiple controller solu- 
tion for industrial users, because cells of robots are be- 
coming larger, and, therefore, the required "locality of 
control" is becoming larger than practical for a single 
controller. For example, to support one or more of the 
above listed coordinated activities in a cell with eight ro- 
bots requires a controller capable of controlling over 48 
axes, which is not commonly available and not practical. 
With the present invention, such a controller is not need- 
ed. 

[0027] Accordingly, the general object of the invention 
is to provide a method and a robot control system for 
controlling multiple robots where various forms of coor- 
dinated motion are required among the robots and the 
controllers for those machines are connected via a 
standard computer communication line. 
[0028] The invention solves the aforementioned mo- 
tion coordination problems among the robots by provid- 
ing a method of the above-mentioned kind wherein time 
coordinated motion instructions are defined and execut- 
ed by said control program, each such time coordinated 
motion instruction with unique label, such that informa- 
tion is communicated among said plurality of controllers 
and wherein robot motion produced by like labeled time 
coordinated motion instructions executed on any of said 
plurality of controllers executes in such a way that they 
jointly begin at a first time, follow a common relative ve- 
locity profile, and jointly end at a second time. 
[0029] To solve the aforementioned problems, the in- 
vention furtheron provides a system of the above-men- 
tioned kind wherein said control program is arranged for 
defining and executing a uniquely labeled time coordi- 
nated motion instruction for communicating information 
among said plurality of controllers and wherein said con- 
trollers are arranged for synchronized execution of like 
labeled time coordinated motion instructions such that 
said instructions execute in such a way that they jointly 
begin at a first time, follow a common relative velocity 
profile, and jointly end at a second time. 
[0030] Preferentially, said motion instruction source is 
local to the controller. However, in a alternative embod- 
iment said motion instruction source which may be a 
control program, can also be remote from the controller. 
[0031 ] Each robot controller contains at least one mo- 
tion system capable of controlling attached robotic ma- 
chines (robots). However, the invention relates in par- 
ticular to coordination problems between robots control- 
led by separate controllers. Each controller may also 
contain at least one motion instruction source, or it may 
contain no motion instruction source, and the motion in- 
structions for that controller may originate remotely. The 



invention specifically relates to coordination problems 
where motion instruction sources are on separate con- 
trollers. 

[0032] A motion instruction source includes but is not 
5 limited to instruction sources like a control program in- 
terpreter, a directly executed compiled control program, 
a manual motion pendant device, or any operator device 
designed to give a human operator control of robot mo- 
tion. 

10 [0033] Another aspect of the invention is the ability to 
link the motion of a "dependent frame of reference" as- 
sociated with some point on one robot to an "independ- 
ent frame of reference" associated with some point on 
a different robot controlled by a different controller. The 

'5 motion of the dependent frame of reference depends on 
the motion of the independent frame of reference. When 
the independent frame moves, so does the dependent 
frame. However, if the dependent frame is moved the 
independent frame does not necessarily move. 

20 [0034] To this end, the invention particularly relates to 
a system for controlling a plurality of robots, said system 
comprising a plurality of controllers, each having an as- 
sociated motion system adapted to control attached ro- 
bots; at least one of said controllers having at least one 

25 motion instruction source; a computer network over 
which said controllers communicate; at least one first 
controller of said plurality of controllers having a position 
sending system for sending a commanded position of 
said attached robot over said network; at least one sec- 

30 ond controller of said plurality of controllers having a po- 
sition receiving system for receiving said commanded 
position over said network from at least one of said first 
controllers; said second controller arranged for defining 
at least one first robot reference frame with a fixed po- 

35 sition relative to some point on said robot attached to 
said first controller (independent reference frame) and 
at least one second robot reference frame with a fixed 
position relative to some point on said robot attached to 
said second controller; said second controller arranged 

40 for maintaining a certain spatial transformation relation- 
ship (dependency relationship) between said second ro- 
bot reference frame (dependent reference frame) and 
said independent reference frame; said relationship 
specified by said motion instruction source of said sec- 

45 ond controller. 

[0035] Concerning the same aspect of the invention, 
the latter furtheron relates to a method for controlling a 
system of a plurality of robots, said system further com- 
prising a plurality of controllers, each having an associ- 

50 ated motion system adapted to control attached robots; 
at least one of said controllers having at least one motion 
instruction source; and a computer network over which 
said controllers communicate, wherein at least one first 
controller of said plurality of controllers sends a com- 

55 manded position of its attached robot over said network, 
wherein at least one second controller of said plurality 
of controllers receives said commanded position over 
said network from said first controller, wherein said sec- 
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ond controller defines at least one first robot reference 
frame with a fixed position relative to some point on said 
attached robot of said first controller (independent ref- 
erence frame) and at least one second robot reference 
frame with a fixed position relative to some point on said 
attached robot of said second controller, wherein said 
second controller by using said commanded position 
maintains a spatial transformation relationship (depend- 
ency relationship) between said second robot reference 
frame (dependent reference frame) and said independ- 
ent reference frame by moving its attached robot to 
maintain said transformation relationship and wherein 
said dependency relationship is defined by a motion in- 
struction source of said second controller. Preferably 
said spatial transformation relationship is a Cartesian 
transformation relationship. 

[0036J While association of a motion of one robot to 
that of another robot has been done in the prior art, prior 
systems have either focused on subjecting all of the ro- 
bots to the control of common controller, or, where the 
robots are on separate controllers, such an association 
was only possible during the execution of specific con- 
trol programs (see above). 

[0037] According to the invention, a dependent frame 
of reference keeps its relationship to an independent 
frame of reference at all times, even while the corre- 
sponding controller switches between instruction sourc- 
es. This is particularly important when switching from 
production operation to manual operation while two ro- 
bots are carrying a part. Preferably, said spatial relation- 
ship is a Cartesian transformation relationship. 
[0038] The invention provides this capability by main- 
taining knowledge of the independent frame of refer- 
ence on the controller where the dependent frame of ref- 
erence is defined. In this way, any instruction source 
providing motion instructions to that controller's motion 
system may provide those instructions relative to the in- 
dependent frame of reference. 
[0039] In order to achieve this, in a preferred embod- 
iment of the inventive system, said second controller is 
arranged for maintaining said transformation dependen- 
cy relationship between a dependent reference frame 
and an independent reference frame while there is no 
command from any one of said motion instruction sourc- 
es of said second controiler and/or when said second 
controller changes from one of said instruction sources 
to another. The persistent knowledge of the independ- 
ent frame of reference is maintained in the background 
by a transmission of state information between the con- 
troller of the robot FOR which the independent frame is 
defined and the controller ON which the independent 
frame is defined. This in turn is done using a subscription 
by the controller ON which the independent frame is de- 
fined to the controller of the robot FOR which the frame 
is defined. Also, a controller for one robot may keep mul- 
tiple subscriptions to different independent frames si- 
multaneously. 

[0040] In a preferred embodiment of the inventive 



method said second controller maintains said transfor- 
mation dependency relationship between said depend- 
ent reference frame and said independent reference 
frame while there is no command from any of said mo- 

5 tion instruction sources of said second controller and/or 
when said second controller is changing from one of 
said motion instruction sources to another. 
[0041] In this way, using the inventive control method 
and system, several coordination problems can be 

io solved over the prior art where robots are controlied by 
separate controllers: 

- Positions may be taught relative to an independent 
frame of reference for use in motions of the robot 

15 where the dependent frame is defined. That is, ac- 
cording to a further embodiment of the inventive 
method a teaching system of said second controller, 
using said commanded position, records a taught 
position defined relative to said independent refer- 

20 ence frame for later use, such that upon later use 
said second controller causes said second robot 
reference frame to follow a path prescribed by a mo- 
tion instruction source of said second controller to 
said taught position. In a preferred embodiment of 

25 the inventive system a teaching system of said sec- 
ond controller is arranged for recording taught po- 
sitions defined relative to an independent reference 
frame for later use. 

30 - By moving the TCP of a robot to a position defined 
relative to an independent frame, the TCP becomes 
a dependent frame of reference, and this depend- 
ency remains persistent. Even after termination of 
the motion, the TCP remains dependent, and will 

35 move automatically whenever the independent 
frame moves. In general, according to a further em- 
bodiment of the inventive method said dependency 
is created by a motion of said second robot refer- 
ence frame to a position defined relative to said in- 

40 dependent reference frame from a position defined 
relative to a reference frame different from said in- 
dependent reference frame. Accordingly, in the in- 
ventive system said motion instruction source of 
said second controller preferably is arranged for 

45 creating said dependency relationship between a 
second robot reference frame and said independ- 
ent reference frame. 

The motion to a destination is automatically carried 
so out relative to the independent frame of reference. 
The robot for which the independent frame is de- 
fined may be moved anytime and the motion issued 
by the instruction source for the dependent frame 
will remain the correct relative motion. In another 
55 embodiment of the inventive system said motion in- 
struction source of said second controller is ar- 
ranged for issuing a relative motion instruction such 
that said dependency relationship of said second 
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controller is a motion of said dependent reference 
frame defined relative to said independent refer- 
ence frame. 

Since the independent frame of reference is con- 
stantly maintained, manual motions may also be 
carried out relative to that frame of reference. When 
the manual motion stops, the dependent frame will 
stop relative to the independent frame. 

It is possible to carry out a motion of a robot from a 
stationary frame, e.g. defined relative to world to an 
independent frame defined on a moving robot. In 
order to avoid an instantaneous change in velocity 
form 0 to the velocity of the moving independent 
frame, state information, such as velocity and ac- 
celeration of the independent frame may also be 
kept. Thus a smooth motion onto or off the inde- 
pendent frame may be planned. It is therefore also 
possible to issue motions of the TCP of a first robot 
from an independent frame on a second robot to an 
independent frame on a third robot. The TCP mo- 
tion will start at 0 speed relative to the second robot, 
move smoothly and stop at 0 speed relative to the 
third robot. This capability is important to permit one 
robot to rendezvous with and depart from a frame 
of reference defined on a second robot. 

Historically, in the prior art, this is similar to ro- 
bots moving onto and off of moving conveyor sys- 
tems. However, in those systems, the conveyor 
sensors are connected directly to the same control- 
ler as the robots. In the prior art where robots are 
on separate controllers, no such rendezvous and 
departure is provided for between one robot and an- 
other. 

According to a further development of the inventive 
method said dependent reference frame defined 
with respect to a robot attached to a first controller 
is defined as an independent reference frame with 
respect to said robot by a different controller. This 
is true because a controller can subscribe to frame 
information from another controller at the same time 
it publishes the same information to a third. For ex- 
ample, this permits one robot to be taught weld 
points on a small part that is in turn held by a second 
robot relative to a large part held by a third. 

[0042] While the previous aspect of the invention sup- 
ports spatial coordination activities among robots, tem- 
poral coordination is sometimes also necessary. In the 
prior art, where two or more robots are controlled by the 
same controller, it is possible to move one robot simul- 
taneously with another by simply issuing the motion 
from one control program instruction to both robots. This 
is necessary in order to coordinate a spatial relative mo- 
tion of a robot R2 relative to a robot R1 simultaneously 
to a motion of robot R1. In prior art of arc welding for 



example, it is very common to move a robot relative to 
a table positioner in time coordination with the motion of 
that positioner. This is how a molten puddle can be kept 
in its intended run, e.g. horizontal while the robot 

s traverses the weld seam. 

[0043] However, when the instruction sources reside 
on separate controllers, a single instruction cannot be 
issued. Therefore, another aspect of this invention is to 
permit temporally synchronized motions from multiple 

10 motion instruction sources. As indicated above, the in- 
vention therefore involves a new kind of motion state- 
ment, communication and coordination between con- 
trollers to carry out synchronized motions on the sepa- 
rate robots. To this end, the system according to the in- 

is vention is characterized in that said control program is 
arranged for defining and executing a uniquely labeled 
time coordinated motion instruction for communicating 
information among said plurality of controllers and 
wherein said controllers are arranged for synchronized 

20 execution of like labeled time coordinated motion in- 
structions such that said instructions execute in such a 
way that they jointly begin at a first time, follow a com- 
mon relative velocity profile, and jointly end at a second 
time. 

25 [0044] As stated above, the synchronized motion 
statement uses a unique label on the statement. Each 
control program running on its own controller will wait at 
the synchronized motion statement for control programs 
on ail other controllers to reach the same labeled state- 

30 ment. Then, each motion system running on its own con- 
troller will coordinate the motion planning of its motion 
along with all other controllers, so that all robots carry 
out their motions with the same motion profile. That is, 
they all start, accelerate, move at constant speed, and 

35 decelerate together, thus reaching their destinations at 
exactly the same time. The robot requiring the most time 
for its motion will govern all others to take the same time. 
[0045] Another aspect of the invention is the improve- 
ment of accuracy by use of clock alignment. Several 

40 methods and standards now exist for aligning clocks 
across a communication line, as discussed above. How- 
ever, it is necessary that interpolators and subinterpola- 
tors be aligned so that the actual output from servo sys- 
tems occur at the same time. 

45 [0046] Therefore, the system according to the inven- 
tion preferably comprises an associated clock for each 
controller that produces timing information based on a 
temporal reference frame; and a system for supplying a 
synchronization signal to said controllers that periodi- 

50 cally aligns the temporal reference frames of said 
clocks; said controllers being arranged for using said 
clocks to control said associated motion systems such 
that said attached robots controlled by said motion sys- 
tems operate with clock-alignment. 

55 [0047] Accordingly, the inventive method preferably is 
characterized in that an associated clock in each con- 
troller produces timing information based on a temporal 
reference frame; wherein a system for supplying a syn- 
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chronizing signal to said controllers periodically aligns 
the temporal reference frames of said clocks; and 
wherein said controllers use said clocks to control said 
associated motion systems such that said attached ro- 
bots controlled by said motion systems operate with 
clock-alignment. 

[0048] The invention thus provides for the hardware 
clocks on the plurality of robot controllers to be aligned 
with each other so that the subinterpolation intervals are 
aligned, and it provides for interpolator interval align- 
ment as well. 

[0049] I n a preferred embodiment of the inventive sys- 
tem said clocks are hardwired to said controllers. 
[0050] In another preferred embodiment of the inven- 
tive method a signal with a first frequency and phase is 
used to adjust the phase of one of said clocks operating 
at a second higher frequency on each of the plurality of 
controllers to make the phases of said higher frequency 
clocks the same in all of said plurality of controllers; and 
wherein said first frequency signal is proportional to the 
out-of-phase-ness. To this end, in another embodiment 
of the inventive system, said clocks are connected to 
said controllers via phase locking means, said phase 
locking means comprising a serial synchronizing con- 
nection and/or an Ethernet connection. 
[0051 ] The result is that time coordination in time syn- 
chronized motions is nearly perfect, and no position 
alignment error due to clock alignment is introduced in 
spatially coordinated motions. 
[0052] The invention will now be described in more 
detail with reference to the accompanying drawings 
which show preferred embodiments of the inventive 
method and system. 

Fig. 1 is a diagram of the general system archi 

lecture supported by the invention; 

Fig. 2 shows an example of linked motion of two 

robots; 

Fig. 3 is a diagram showing the task level archi- 

tecture of the preferred embodiment; 

Fig. 4a, 4b show a flow diagram for the Motion State 
Publisher task; 

Fig. 5a, 5b show a flow diagram for the Motion Inde- 
pendent Frame Subscription Service 
task; 

Fig. 6a, 6b show a flow diagram for the Motion Plan- 
ner task; 

Fig. 7 is a flow diagram for the Motion Interpo- 

lator task; 

Fig. 8 shows messages and timing for a typical 

linked motion; and 



Fig. 9a, 9b show messages and timing for typical 
synchronized motions under various sce- 
narios. 

5 [0053] Fig. 1 illustrates the general architecture of a 
control system according to the invention. Inside a work 
cell 1 are present multiple robots R1-R4. Each robot 
R1-R4 is connected for signal transmission to a robot 
controller RC-RC", whereby multiple robots R3, R4 can 

w be connected to a common controller RC M . Each con- 
troller RC-RC" has an associated motion system 
MS-MS" and is arranged to receive motion instructions 
from at least one motion instruction source MIS-MIS< 3 > 
which can be either local to the controller, e.g. motion 

is instruction sources MIS, MIS', MIS< 3 >or remote from the 
controller as is the case for controller RC* in Fig. 1 . 
[0054] At least one MIS" of the motion instruction 
sources may be devised as a control program. 
[0055] The individual controllers are physically linked 

20 via a computer network 2, which in the embodiment 
shown in Fig. 1 comprises a hub 3 for communication 
distribution services. An important point conveyed by 
Fig. 1 is that all aspects of the invention are valid wheth- 
er motion instruction sources MIS-MIS< 3 ) are on the 

25 same controller or different controllers. Furtheron, one 
robot controller RC has a position sending system PSS 
for communicating positions of its attached robot R2 
over the network 2. Another controller RC" has a corre- 
sponding position receiving system PRS for receiving 

30 said positions over the network 2. 

[0056] Fig. 2 shows an example of linked motion in- 
volving two robots R1 , R2. One robot R1 carries a part 
4 along a motion trajectory T (though the latter need not 
be a straight line), while another robot R2 carries out a 

35 process relative to the part 4, such as arc welding along 
a weld line W. An important aspect of the invention illus- 
trated in Fig. 2 is that the process robot R2 can rendez- 
vous (rendezvous motion RM) and depart (depart mo- 
tion DM) from the part 4 while the latter is in motion along 

*o the trajectory T. During processing of part 4 by robot R2, 
the two robots are in linked relative motion, robot R1 
along the trajectory T and robot R2 along a generally 
curved trajectory L. 

[0057] The overall task architecture of the preferred 
45 embodiment is shown in Fig. 3. It assumes a tasking 
architecture which can be supported by many commer- 
cial real-time operating systems available today. The 
motion system task architecture is divided between mo- 
tion instruction sources MIS-MIS" (cf. Fig. 1) which are 
50 internally or remotely connected to a motion system MS 
associated with a robot controller RC (Fig. 1). 
[0058] The motion system MS comprises a manual 
motion generator MS.1 in connection with manual mo- 
tion instruction sources MIS, e.g. teaching pendants 
55 etc., if the latter are present. Software- implemented in- 
struction sources, i.e. control programs MIS', MIS" are 
connected to a motion planner MS.2 which relays infor- 
mation to a motion state manager and publisher MSP 
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via a motion interpolator MS.3. Information generated 
by the motion generator MS.1 is relayed directly to the 
MSP. 

[0059] The MSP comprises a subscriber list MS.4 
containing information, e.g. network addresses of mul- 
tiple subscripers on the other controllers who have de- 
fined independent reference frames associated with ro- 
bots attached to the present controller. These subscrib- 
ers may include manual motion systems, planners, and 
interpolators such as MS.1 , MS.2 and MS.3, respective- 
ly- 

[0060] Further shown in Fig. 3 is an independent 
frame subscription service IFSS for gathering robot 
state messages from individual publishers, i.e. the 
MSPs of motion systems MS on another controller as 
shown in Fig. 3. Through a subscription list MS.5 the 
IFSS relates independent frames defined on the current 
controller to robot motion state publishers of other con- 
trollers. 

[0061] Key aspects of the architectures that support 
the invention are: 

the background Independent Frame Subscription 
Service task IFSS for maintaining updated state in- 
formation about remote frame publishers whether 
programs are running or not and whether relative 
motions are in-progress or not; 

a Motion State Manager task for maintaining the po- 
sition of a robot relative to a remote independent 
frame, independent of whether programs are run- 
ning or not and whether relative motions are in- 
progress or not; and 

the motion state of a robot being kept persistent rel- 
ative to a remote independent frame for either man- 
ual motions or programmed motions or during tran- 
sitions between them. 

[0062] The following points are to be noted with re- 
spect to the embodiment shown in Fig. 3: 
[0063] Multiple instruction sources MIS-MIS" may be 
present simultaneously. This includes a manual motion 
source MIS and multiple control program instruction 
sources MIS', MIS". The dotted line below these in Fig. 
3 indicates that the instruction sources may reside on 
the same or different controller as the motion system 
controlling the robot (Fig. 1). 
[0064] The architecture shown permits continuous 
and persistent linking between a dependent reference 
frame on one robot and the independent reference 
frame defined on another robot while changing between 
motion instruction sources located anywhere and in- 
cluding either manual motion sources or control pro- 
gram instruction sources, and it includes such persist- 
ence even while no motion instruction is coming from 
any motion source. 

[0065] Various motions can be planned or executed 



which make use of multiple different independent refer- 
ence frames simultaneously as shown by messages 
coming from multiple publishers to the Independent 
Frame Subscription Service IFSS and by that service's 

s ability to update planners, inter-polars, and manual mo- 
tion systems simultaneously. Functioning of the IFSS is 
described in detail below. In this way, it is possible to 
plan a motion from a currently moving independent ref- 
erence frame to another moving independent reference 

10 frame, wherein such motion is to be started sometime 
in the future. 

[0066] The Motion State Manager is able to publish a 
robot's faceplate position to multiple subscribers simul- 
taneously. 

*9 [0067] For motion planning, the Planner MS.2 uses 
an estimate of the future position of an independent ref- 
erence frame. In this way, when the actual motion in that 
frame begins, a correction factor is started and interpo- 
lated to nil by the Motion State Manager MSP. This is 

20 how motions between various moving reference frames 
can be handled smoothly and with advanced planning. 
These kinds of motions are generally transition motions 
that do not require substantial precision. Precision mo- 
tions are generally generated in the same frame of ref- 

25 erence, where no correction is needed between mo- 
tions. 

[0068] The motion systems architecture can work in 
the presence of servo and interpolation clock synchro- 
nization between robot controllers or in the absence of 

30 such synchronization. There is also no requirement that 
the interpolation interval of two robot controllers be the 
same. Each component of the architecture assumes 
that wherever an independent frame is needed, its full 
state is available, including at least its velocity and po- 

35 sition. Other derivatives, e.g. acceleration may option- 
ally be present. 

[0069] In the presence of clock synchronization, it is 
assumed that each robot controller generates its face- 
plate updates at the same rate and at nearly the same 

40 relative times within its interpolation interval. Chaining 
is then suppored in the following way: The MSP of each 
robot waits for up to a fixed amount of time for the frame 
update from its remote publisher, to which it is sub- 
scribed. This delay is sufficient for two or more succes- 

45 sive robot controllers to compute their faceplate position 
and pass them on to their subscribers. All controllers will 
then update their servo systems at exactly the same 
time on the subsequent clock tick. 
[0070] In the absence of clock synchronization, a 

so timeout from the above delay may occur. In this case, 
an estimate of the publisher's frame state is made, 
based on previously updated positions and velocities 
and the known time interval from the update time to the 
current time. 

55 [0071] In practice, the estimate of frame state is al- 
ways used. However, when clock synchronization is 
used, the time interval between update and usage of 
said estimate is 0 clock intervals, and thus the position 
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is accurate. 

[0072] Details of these general ideas are now pre- 
sented in the following paragraphs: 
[0073] The Motion State Publisher MSP can also act 
as a motion state manager. One of the key ideas of the 
invention is that it must be possible for a robot to remain 
in motion while there is no motion actually being gener- 
ated on the controller for that particular robot. In a typical 
robot controller according to the prior art, when the in- 
terpolator has finished interpolating a particular motion, 
motion of the robot stops. Similarly, if under manual mo- 
tion control, when the operator lifts a button causing mo- 
tion, motion stops. 

[0074] In the preferred embodiment according to the 
invention, the MSP permits linked motion to continue in 
the absence of motion from the above entities. Together 
with the IFSS, described in detail below, these two com- 
ponents provide a significant difference from the prior 
art that permit the solution of all the previously described 
coordination problems. 

[0075] Planning of motions is generally done in ad- 
vance of their actual execution: It is therefore possible 
that an assumed starting position is slightly different 
than the actual starting position, because in the case 
where the new motion is relative to a different frame than 
that of the current motion, that new frame might have 
taken a slightly different trajectory than assumed by the 
Planner or Manual Motion Generator. 
[0076] The MSP generates a small correction trans- 
formation at the beginning of each motion, so that such 
a transition motion from one frame to another frame is 
smooth. The correction transform is then interpolated to 
nil during the motion using a well known single-angle 
interpolation algorithm, so that the terminal position is 
exactly correct relative to the new frame. The single-an- 
gle interpolation algorithm determines the common nor- 
mal vector between like coordinates of the assumed and 
actual starting position and then interpolates the rotation 
about that vector from actual to assumed starting posi- 
tion. This interpolation occurs linearly throughout the 
course of the motion. 

[0077] Furtheron, the MSP is responsible for the final 
calculation of the robot's faceplate position and joint an- 
gles for each interpolation interval. It is thus responsible 
for publishing that position to subscribers that have de- 
fined independent frames of reference relative to this ro- 
bot's faceplate. This supports chaining of reference 
frames. 

[0078] The MSP additionally supports linking and 
chaining with and without servo and interpolation clock 
synchronization in the following way: When it requests 
independent frame state update from the IFSS it does 
so by specifying an allowable timeout value. The IFSS 
will then satisfy the update request with the actual up- 
date if it occurs prior to timeout (the normal case with 
clock synchronization) or with an estimate if the timeout 
occurs before an update takes place (possible without 
clock synchronization). 



[0079] Referring to the details of the flowchart in Fig. 
4a, 4b the MSP performs the following operations: 
[0080] After the MSP starts in step S1 (Fig. 4a), the 
MSP task first waits for the next interpolation cycle of 

5 the robot control in step S2, e.g. by repeatedly checking 
for a corresponding signal issued by a motion interpo- 
lator or other motion sources (not shown) as illustrated 
by loop S2'. Previous cycles of the MSP may have gen- 
erated messages to subscriber tasks and entries for 

w those messages may have been entered in a response 
Q. At step S3, this response Q is checked. Positive re- 
sponses from previous messages are simply removed. 
However, if no response came within a critical timeout 
period for an entry in this Q, this is a serious error. In 

'5 case of a timeout for an entry in this Q, a STOP mes- 
sages will be sent to the motion source (interpolator or 
manual motion generator). 

[0081] In a subsequent step S4, the MSP checks for 
relative motions in progress and for upcoming new rel- 

20 ative motions, which are characterized by updates in Q. 
If there are such motions present, position is being up- 
dated and the MSP will get the next desired Cartesian 
state of a dependent frame from an interpolator or an- 
other motion generator (step S5). Preferably, the state 

25 message also contains a description of the frame (e.g. 
in terms of axes' orientation) as well as information on 
tools, velocities and the percentage of motion that has 
already been carried out. The absence of such motions 
characterizes a stationary state relative to an independ- 

30 ent frame such that previous values can be used for cor- 
rection and desired position, and the task proceeds di- 
rectly to step S6, wherein the MSP requests independ- 
ent frame state update from the IFSS (Fig. 3) using a 
maximum possible timeout. I n the case where clock syn- 

35 chronization is used between controllers, the IFSS will 
respond within this timeout period with an update that 
represents an independent frame from a different con- 
troller in the same clock interval. When clock synchro- 
nization Is not used, the IFSS will usually timeout, and 

40 in that case it will estimate the independent frame posi- 
tion for the current time. 

[0082] In a subsequent step S7, the MSP checks 
whether or not this is the start of a new motion. In case 
of a new motion, the MSP assumes a new start position 

45 and calculates for a new frame a new initial correction 
transform (step S8). Subsequently, if the new motion us- 
es a new frame, then a message is sent to the IFSS (Fig. 
3) to release (unsubscribe) the old frame (step S9). If 
there is no new motion, there either is no motion in 

so progress, or an ongoing motion is not yet complete 
(somewhere between 0 and 100% complete). In this 
case, the task is resumed directly in step S10 (Fig. 4b), 
wherein the correction transform (step S8; Fig. 4a) is 
interpolated based on the percentage of motion from an 

55 interpolator or another motion generator. In subsequent 
steps S1 1 -S1 4 (Fig. 4b), the MSP calculates a next face- 
plate position relative to World (step S11); for each ex- 
ternal controller in the subscription list (Fig. 3), sends 
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the next anticipated Cartesian state of the faceplate over 
the communication network (cf. Fig. 1) and makes cor- 
responding entries in a Q (step S12) to check for re- 
sponses from the faceplate messages in a subsequent 
cycle (step s3 of the next cycle); calculates next joint s 
angles from the next faceplate position (cf. step S11) 
using inverse kinematics equations and sends joint an- 
gles to a servo subsystem (not shown; step S13); and 
sends any error response and scale back information to 
the publisher of the current frame (step S14). io 
[0083] The IFSS is the second component along with 
the MSP that significantly differentiates the architecture 
of the present invention from the prior art. 
[0084] The IFSS performs the following basic func- 
tions: is 

- it maintains a list of independent frames that are de- 
fined relative to one or more remote robots face- 
plates. There can be multiple frames defined for 
each faceplate. For example, the Planner MS.2 20 
(Fig. 3) can be planning a motion at the same time 

the interpolator is carrying out a motion. The plan- 
ner could be planning a motion relative to a gripper, 
while the interpolator is performing a motion relative 
to a part in the gripper. Both the gripper and the part 25 
represent independent frames being kept by the 
IFFS for simultaneous use by the system. Or the 
Planner can be planning a motion relative to a grip- 
per on one robot while the interpolator is carrying 
out a motion relative to the gripper on another robot; 30 

it maintains a subscription list of remote robot face- 
plates. The IFSS subscribes to a romote faceplate 
when the Planner MS.2 or Manual Motion Genera- 
tor MS.1 is planning a new motion to a new frame 33 
using a new faceplate. The IFSS unsubscribes from 
a remote faceplate when the MSP is finished with a 
motion relative to the last frame defined relative to 
that faceplate. Note that this is usually not at the 
end of a motion's interpolation by the Interpolator, 40 
but rather when a new motion is initiated to a frame 
relative to a different faceplate. 

[0085] Each new frame request generates a new sub- 
scription ID, even if the frame is already being used. 45 
That ID is passed along from Planner to Interpolator, and 
to MSP. When the MSP is finished with a frame ID, it 
sends a release subscription message to IFSS. If said 
ID is the last ID remaining for a particular frame, that 
frame is released, and if the frame is the last one refer- so 
encing a particular faceplate, an unsubscribe command 
is sent to the publisher, and the faceplate is released; 

- it updates all the frames referencing a certain face- 
plate. This includes transforming the incoming face- 55 
plate position, velocity, and any other state informa- 
tion to the independent frame and recording the up- 
date time. This information can then be used for 



subsequent frame state estimation at a future time; 
and 

it responds to frame update requests from the Plan- 
ner, Manual Motion Generator, or MSP. 

[0086] Referring to the details of the flowchart in Fig. 
5a, 5b, the IFSS performs the following operations: 
[0087] The IFSS is started in step S1 (Fig. 5a). It then 
waits for a message in step S2 (loop S2'), which can be 
1) a new frame subscription message from manual mo- 
tion or planners (step S3; Fig. 5a); 2) a remove frame 
subscription message from the MSP (sep S4; Fig. 5a); 
3) a faceplate update message from a remote publisher 
(step S5; Fig. 5b); or 4) a request for latest independent 
frame information message from the MSP, manual mo- 
tion or planner (step S6; Fig. 5b). 
[0088] If the message in step S2 is a new frame sub- 
scription message (step S3; Fig. 5a), then the IFSS 
checks in a subsequent step S3.1 whether or not sub- 
scription to that frame already exists. If a subscription 
exists, the task Is resumed in step S3. 5 (see below). 
Otherwise, in step S3.2 a new entry is created in a list 
of independent frames. Then, in step S3.3, it is checked 
whether or not a reference to the faceplate referenced 
by that independent frame already exists. If such a ref- 
erence exists, the task is resumed in step S3. 5, other- 
wise in step S3.4 an entry is created in a remote face- 
plate data table and a subscribe message sent to the 
faceplate publisher. In subsequent step S3.5 the IFSS 
creates a subscription ID for the frame, with more than 
one ID possible for the same frame. Furtheron, the new 
ID is returned to the requestor, which can be a motion 
planner or a manual motion interface. The task is then 
continued in step S2. 

[0089] if the message in step S2 is a remove subscrip- 
tion message (step S4; Fig. 5a), then the subscription 
ID is removed from the frame (step S4.1) and the IFSS 
checks whether or not all IDs for that frame have been 
removed (step S4.2). If there are still some IDs left, the 
task is resumed in step S2. Otherwise, its entry is re- 
moved from the independent frame list (step S4.3). If ail 
references to that particular faceplate have been delet- 
ed (step S4.4) then in step S4.5 a unsubscribe message 
is sent to the faceplate publisher and the remote face- 
plate is removed from the faceplate date table. Other- 
wise or afterwards, the task is resumed in step S2. 
[0090] If the message in step S2 is a faceplate update 
message (step S5; Fig. 5b) then the remote faceplate 
data is updated in the faceplate data table and a mes- 
sage sent to the publisher to acknowledge the update 
(step S5.1). The task is then resumed in step S2. 
[0091] If the message in step S2 is an independent 
frame request message (step S6; Fig. 5b), then the IFSS 
waits with specified timeout for an update message from 
a described faceplate. Any other messages are put in 
another wait queue (step S6.1). Step S6.1 is repeated 
until the update message is received as illustrated by 
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loop S6.1V Then in a subsequent step S6.2, the remote 
faceplate data in the faceplate data table is updated for 
an update within timeout (step S6.2). The IFSS then cal- 
culates current faceplate position in step S6.3 using: 
(latest velocity update) x (time since latest update) + (lat- s 
est update position). In step S6.4, the requested inde- 
pendent frame state is calculated using the current face- 
plate calculated in step S6.3 plus the stored offset from 
the faceplate to the requested independent frame. In 
step S6.5, the requested frame state update is returned w 
to the requester. The task is then resumed in step S2. 
[0092] The Planner task (MS.2; Fig. 3) serves the ba- 
sic function of calculating various parameters of the mo- 
tion for later use by the interpolator. The planning of a 
motion is typically done a full motion ahead of the actual '5 
execution of a motion by the interpolator. This planning 
normally occurs in parallel with execution of the previ- 
ously planned motion by the interpolator. In case where 
several motions are queued, i.e. waiting for execution, 
planning may occur several motions ahead of the actual 20 
interpolation of the motion. 

[0093] Among the variables needed for planning a 
motion are the beginning and ending states of the mo- 
tion, including at least starting position and velocity and 
ending position and velocity. Since a motion is planned 25 
for a particular tool center point TCP (tool), and a par- 
ticular frame of reference (frame), the states of the tool 
and frame for the motion must also be known at the time 
of planning. On a single controller, planning motions on- 
ly for the robot attached to that controller and with no 30 
outside sensor influences, all required tool, frame, and 
starting state information is static and can thus be used 
at any time prior to the motion. 
[0094] However, the assumption in the present inven- 
tion is that each motion may be defined with respect to 35 
a new frame of reference, which may in turn be defined 
relative to a moving faceplate of a remote robot. Further, 
the state of the frame needed for planning may not be 
up-to-date at precisely the time the planning is done. 
Even if planning were done at precisely the start of in- *o 
terpolation, unless clock synchronization is used, the in- 
dependent frame information may not be exactly up-to- 
date at that time. 

[0095] A key aspect of the architecture in the pre- 
ferred embodiment according to the invention is the IF- 45 
SS, which supports estimation of future values of inde- 
pendent frames of reference defined relative to a remote 
faceplate. The IFSS will subscribe to and receive up- 
dates for the required remote robot. It will also convert 
the updated remote faceplate state to the independent 50 
frame of reference required by the Planner MS.2 (Fig. 
3). Because full state information is maintained, includ- 
ing position and at least velocity of the independent 
frame, the Planner can then predict the position of the 
frame at the time the motion will be executed by the in- 55 
terpolator. 

[0096] Referring to the details of the flowchart in Fig. 
6a, 6b the Planner performs the following operations: 



[0097] After start of the Motion Planner in step S1 (Fig. 
6a), it waits for a next Control Program Motion instruc- 
tion in step S2. Again, waiting is illustrated by loop S2\ 
After such an instruction has been given, the task 
checks in step S3 whether or not a new frame or tool 
has been added. If such a change has not occurred then 
it calculates parameters for the next motion in step S4. 
If the next motion is to be blended, i.e. a smooth transi- 
tion between old and new motion states is to be per- 
formed, a new final motion is defined, placed back in the 
wait queue, and the current motion is planned as a blend 
motion, i.e. a motion that will join the new final motion 
smoothly in at least some of its parameters. Then, in 
step S5, an interpolation instruction record is sent to the 
interpolator queue, and the task is continued in step S2. 
[0098] If a new frame or tool is detected in step S3, 
then the task further distinguishes between situations 
with a new frame and situations without a new frame in 
step S6 (Fig. 6b): if a new frame is detected then, in step 
S7, for a remote frame the new frame information is sent 
to the IFSS together with a request for a subscription ID. 
Then, in step S8, the task waits and repeatedly checks 
(loop S8*) for a frame update from the IFSS before es- 
timating a independent frame at start time in step S9. 
[0099] Then or in case no new frame was found in 
step S6, in step S10 a start state in the new frame and/ 
or tool is reset. The task is then resumed in step S4 (Fig. 
6a). 

[0100] The calculations performed in the Interpolator 
of the preferred embodiment are typical of existing robot 
controllers. However, instead of sending intermediate 
state information to a servo subsystem, in this case the 
state information is sent to the MSP, which in turn may 
apply a correction factor. The Interpolator passes its cur- 
rent percent of motion completion, so that the MSP may 
apply its interpolated correction factor for the same per- 
centage of completion. In addition, the Interpolator 
passes the subscription ID of the independent frame 
and the tool to be used. The MSP will continue to use 
this same frame and tool for evaluating and updating 
dependent frame state after the motion is completed by 
the Interpolator. 

[0101] Referring to the details of the flowchart in Fig. 
7 the Interpolator according to the invention performs 
the following operations: 

[01 02] After start in step S 1 , the interpolator task waits 
for a new motion in queue Q (step S2), which is checked 
repeatedly (loop S2'). When such motion has been de- 
tected the interpolator waits for the next tick of an inter- 
val clock (step S3; loop S3') and then calculates the next 
interpolated position of a current tool in a current frame 
(step S4). Current frame, tool, position, velocity in frame 
and motion percentage (percentage of motion already 
accomplished) are then sent to the MSP along with a 
subscription ID for any remote frames (step S5). In a 
subsequent step S6, the task performs a check as to 
whether or not the motion has ended. If this is the case, 
the task fetches another from the waiting queue in step 
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S2, otherwise the task is resumed in step S3. 
[0103] The function of the Manual Motion Generator 
(MS.1 ; Fig. 3) is assumed to be typical of existing robot 
controllers, with the exception that it is modified in ex- 
actly the same way as previously described for the Plan- 
ner to make use of estimated frames of reference from 
the I FSS and to pass interpolated state and subscription 
ID information to the MSP in a way similar to the Inter- 
polator. 

[0104] Fig. 8 shows a timing diagram (timelines t) and 
simple linked motion of two robots R1 , R2. Robot R1 
carries a part 4 along a straight line T between end 
points POWorld, P1 World which are defined in World co- 
ordinates. Robot R2 moves a welding torch 5 to the part 
4 while the latter is in motion, stops relative to the part 
4, then departs from the part 4, and moves back to a 
point P2World defined relative to World. Following is a 
description of the communication that occurs during 
these motions: 

motion of R1 along line T is caused by "Move Part- 
InGripperto P1 World ©world", where "X@y" gen- 
erally denotes a position X (point) defined in a par- 
ticular frame of reference y. This moves the part 
held in R1's gripper along the straight line T to po- 
sition P1 World which is defined relative to World co- 
ordinates, e.g. workcell coordinates. No communi- 
cation is caused by this motion; 

- a program on R2 issues "Move Torch to 
P1Part@PartlnGripper M . Since PartlnGripper is an 
independent frame of reference defined on a re- 
mote robot (R1), a message is sent to R1 by R2's 
IFSS to subscribe to R1's faceplate state informa- 
tion. From that time on, R1 cyclically sends its face- 
plate to R2 as previously described. R2's IFSS task 
will respond with acknowledge messages; 

R2's Planner task will plan a motion from 0 velocity 
relative to World to 0 velocity relative to "PartlnGrip- 
per* and from a start position Pstart to final position, 
P1 Part, defined relative to the Part. 

This motion is carried out by R2's interpolator 
and MSP tasks together; 

when the motion of R2 is complete, R2's tasks keep 
the torch 5 at a fixed position relative to the part 4 
and at vanishing relative speed to the part. The pe- 
riodic state messages and responses continue be- 
tween R1 and R2; 

■ R2 issues "Move Torch to P2World@ World". R2's 
Planner plans a motion from 0 velocity relative to 
the part to 0 velocity relative to World and to the final 
position P2World defined in World coordinates. This 
motion is carried out by R2's Interpolator and MSP 
tasks together; 



R2's MSP task unsubscribes from the PartlnGripper 
frame as soon as the motion to P2World begins, be- 
cause PartlnGripper is no longer in use, and the 
faceplate for which it is defined has no other frames 
s defined relative to it in current use; 

- all message traffic stops. The two robots are again 
completely independent from each other. 

w [0105] Important aspects of the diagram shown in Fig. 
8 include: 

- Messages flow in both directions between the two 
robots involved in the linked motion: the state up- 

is date message from publisher to subscriber and re- 
sponse messages from subscriber to publisher. In 
this way, a communication failure can be detected 
by the publisher, or a failure on the subscriber robot 
can be detected, and the robot supporting the inde- 

20 pendent frame can be stopped. 

Rendezvous and departure motions RM and DM, 
respectively, are shown. The robot with the depend- 
ent frame must plan motions to non-stationary po- 
25 sitions during rendezvous, accelerate to moving tar- 
gets, and decelerate from moving start positions 
when departing to stationary positions. 

[0106] Fig. 9a, 9b show timing diagrams for two dif- 
30 ferent sets of time synchronized motions, a simple one 
and a complex one. 

[0107] The simple synchronized motion in Fig. 9a in- 
volves two robots R1 , R2 each executing one time syn- 
chronized motion. Robot R1 is to move to a position 

35 R1P1 at the same time robot R2 moves to a position 
R2P1 (positions not shown in the diagram). The two 
control programs are arranged to recognize that they 
are to synchronize with each other for the motion with a 
same label, e.g. "Step 1 ". They also each know that they 

40 are to synchronize with the other because of the sync 
list, "R1R2" (R1 knows its partner is R2, R2 knows its 
partner is R1 ). The corresponding statements of the pro- 
gram code are given above and below the timelines t, 
respectively. 

45 [0108] The example in Fig. 9a assumes that RVs con- 
trol program arrives at its motion statement first, and its 
Planner issues a message to R2 saying that it is at label 
"Stepl" and it will need 3.4 s to execute its motion. RVs 
Planner then waits for a message from R2. 

50 [0109] Later, R2 arrives at its motion statement. Its 
Planner issues a message to R1 saying that it is at label 
"Stepl" and it will need 2.B s to execute its motion. R2 
already has its message from R1 . Its sync list is satis- 
fied, and it knows the motion of R1 will take the longest 

55 of the two times, i.e. 3.4 s (vs. 2.8 s for R2). Its Planner 
finishes and issues a scaled motion planning with a du- 
ration of 3.4 s to its Interpolator. Scaled motion planing 
means that the speed of each robot is scaled slightly 
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downward from its programmed value to maintain time 
coordination with the other robots. The robot taking the 
longest to execute its motion will dictate the scaling for 
all other robots. The Interpolator then waits for a "Go" 
signal from R1 . (The robot taking the longest time issues 
the "Go'-signal.) 

[01 10] When R1's Planner receives the message 
from R2, its sync list is then satisfied and it issues a mo- 
tion to its Interpolator for 3.4 s. RVs Interpolator sends 
"Go" to R2, and they both begin interpolation. 
[0111] When clock synchronization is used, the "Go" 
signal is given at the beginning of both robots' interpo- 
lation cycles, and they both interpolate in lock step (with 
no need for communication other than clock synchroni- 
zation). The registration between robots is extremely 
precise, as precise as the clock synchronization itself. 
[0112] A much more complex series of synchronized 
motions is illustrated in Fig. 9b. It shows nine motions 
issued by control programs on three different robots 
R1-R3. Robot R1 issues four motions, two of which are 
synchronized with other robots. Robot R2 issues three 
motions, all of which are synchronized with other robots, 
and robot R3 issues two motions, both synchronized 
with other robots. 

[0113] The three synchronization labels are "Stepl", 
"Step2" and "Step3". Robots R1 and R2 participate to- 
gether at Stepl . Robots R2 and R3 participate together 
at Step2. Robots R1 , R2 and R3 participate together at 
Step3. 



Claims 



erence frame; 

wherein a system for supplying a synchronizing sig- 
nal to said controllers periodically aligns the tempo- 
ral reference frames of said clocks; and 
5 wherein said controllers use said clocks to control 
said associated motion systems such that said at- 
tached robots controlled by said motion systems 
operate with clock-alignment. 

10 3. The method according to claim 2, 

wherein a signal with a first frequency and phase is 
used to adjust a phase of one of said clocks oper- 
ating at a second higher frequency on each of the 
plurality of controllers to make the phases of said 

is higher frequency clocks the same in all of said plu- 
rality of controllers; and 

wherein said first frequency signal is proportional to 
the out-of-phase-ness. 

20 4. The method according to one of claims 1 to 3, 
wherein further an associated clock in each control- 
ler produces timing information based on a tempo- 
ral reference frame; wherein a system for supplying 
a synchronizing signal to said controllers periodical- 
's |y aligns said temporal reference frames of said 
clocks; and wherein said controllers use said clocks 
to control said associated motion systems such that 
said attached robots controlled by said motion sys- 
tems operate with clock-alignment. 

30 

5. A method for controlling a system of a plurality of 
robots, said system further comprising: 



1. A method for controlling a system of a plurality of 
robots, said system comprising: 35 

a plurality of controllers, each having an asso- 
ciated motion system controlling attached ro- 
bots and receiving motion instructions from at 
least one motion instruction source, and *o 
a computer network over which said controllers 
communicate; 

wherein time coordinated motion instructions are 
defined and executed by said control program, each 
such time coordinated motion instruction with 
unique label, such that information is communicat- 
ed among said plurality of controllers; and 
wherein robot motion produced by like labeled time 
coordinated motion instructions executed on any of so 
said plurality of controllers executes in such a way 
that they jointly begin at a first time, follow a com- 
mon relative velocity profile, and jointly end at a sec- 
ond time. 

55 

2. The method according to claim 1 , 

wherein an associated clock in each controller pro- 
duces timing information based on a temporal ref- 



a plurality of controllers, each having an asso- 
ciated motion system adapted to control at- 
tached robots; 

at least one of said controllers having at least 

one motion instruction source; and 

a computer network over which said controllers 

communicate; 

wherein at least one first controller of said plurality 
of controllers sends a commanded position of its at- 
tached robot over said network; 
wherein at least one second controller of said plu- 
rality of controllers receives said commanded posi- 
tion over said network from said first controller; 
wherein said second controller defines at least one 
first robot reference frame with a fixed position rel- 
ative to some point on said attached robot of said 
first controller (independent reference frame) and 
at least one second robot reference frame with a 
fixed position relative to some point on said at- 
tached robot of said second controller; 
wherein said second controller by using said com- 
manded position maintains a spatial transformation 
relationship (dependency relationship) between 
said second robot reference frame (dependent ref- 
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erence frame) and said independent reference 
frame by moving its attached robot to maintain said 
transformation relationship; and 
wherein said dependency relationship is defined by 
a motion instruction source of said second control- 
ler. 

6. The method according to claim 5, wherein said spa- 
tial transformation relationship is a Cartesian trans- 
formation relationship. 

7. The method according to claim 5 or 6, 

wherein a teaching system of said second control- 
ler, using said commanded position, records a 
taught position defined relative to said independent 
reference frame for later use, such that upon later 
use said second controller causes said second ro- 
bot reference frame to follow a path prescribed by 
a motion instruction source of said second control- 
ler to said taught position. 

8. The method according to one of claims 5 to 7, 
wherein said dependency is created by a motion of 
said second robot reference frame to a position de- 
fined relative to said independent reference frame 
from a position defined relative to a reference frame 
different from said independent reference frame. 

9. The method according to one of claims 5 to 8, 
wherein said second controller maintains said 
transformation dependency relationship between 
said dependent reference frame and said inde- 
pendent reference frame while there is no com- 
mand from any of said motion instruction sources 
of said second controller and/or when said second 
controller is changing from one of said motion in- 
struction sources to another. 

10. The method according to one of claims 5 to 9, 
wherein said dependent reference frame defined 
with respect to a robot attached to a first controller 
is defined as an independent reference frame with 
respect to said robot by a different controller. 

11. The method according to one of claims 5 to 10, 
wherein the spatial transformation relationship (de- 
pendency relationship) of the at least second con- 
troller is a motion of a second robot reference frame 
defined relative to an independent reference frame, 
said relative motion instruction issued by a motion 
instruction source of said at least second controller. 

12. The method according to one of claims 5 to 11, 
wherein the spatial transformation relationship (de- 
pendency relationship) of the at least one second 
controller is a motion of a second robot reference 
frame defined relative to an independent reference 
frame, said relative motion instruction issued by a 



motion instruction source of said at least one sec- 
ond controller. 

13. A method for controlling a system of a plurality of 
5 robots, said system further comprising: 

a plurality of controllers, each having an asso- 
ciated motion system controlling attached ro- 
bots; 

10 at least one of said controllers having at least 

one motion instruction source; and 
a computer network over which said controllers 
communicate; 

is wherein at least one first controller of said plurality 
of controllers sends a commanded position of an 
attached robot over said network; 
wherein at least one second controller of said plu- 
rality of controllers receives said commanded posi- 

20 tion over said network from said first controller; 

wherein said second controller defines at least one 
first robot reference frame with a fixed position rel- 
ative to some point on said attached robot of said 
first controller (independent reference frame) and 

25 at least one second robot reference frame with a 
fixed position relative to some point on said at- 
tached robot of said second controller; 
wherein said second controller by using said com- 
manded position maintains a spatial transformation 

30 relationship (dependency relationship) between 
said second robot reference frame (dependent ref- 
erence frame) and said independent reference 
frame by moving the attached robot to maintain said 
transformation relationship; 

35 wherein said dependency relationship is defined by 
a motion instruction source of said second control- 
ler; 

wherein further an associated clock in each control- 
ler produces timing information based on a tempo- 
re ral reference frame; 

wherein a system for supplying a synchronizing sig- 
nal to said controllers periodically aligns said tem- 
poral reference frames of said clocks; and 
wherein said controllers use said clocks to control 
45 said associated motion systems such that said at- 
tached robots controlled by said motion systems 
operate with clock-alignment. 

14. The method according to claim 13, 

so wherein a teaching system of said second control- 
ler, using said commanded position, records a 
taught position defined relative to said independent 
reference frame for later use, such that upon later 
use said second controller causes said second ro- 

55 bot reference frame to follow a path prescribed by 
a motion instruction source of said second control- 
ler to said taught position. 
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15. The method according to claim 13 or 14, wherein 
said dependency is created by a motion of said sec- 
ond robot reference frame to a position defined rel- 
ative to said independent reference frame from a 
position defined relative to a reference frame differ- 
ent from said independent reference frame. 

16. The method according to one of claims 13 to 15, 
wherein said second controller maintains said fixed 
transformation dependency relationship between 
said dependent reference frame and said inde- 
pendent reference frame while there is no com- 
mand from any of said motion instruction sources 
of said second controller and/or when said second 
controller is changing from one of said motion in- 
struction sources to another. 

17. The method according to one of claims 13 to 16, 
wherein said dependent reference frame defined 
with respect to a robot attached to a first controller 
is defined as an independent reference frame with 
respect to said robot by a different controller. 

18. A system for controlling a plurality of robots, said 
system comprising: 

a plurality of motion controllers, each having an 
associated motion system controlling an at- 
tached robot, with each of said motion control- 
lers being able to receive motion instructions 
from at least one motion instruction source and 
at least one of said motion instruction sources 
being a control program; and 
a computer network over which said controllers 
communicate; 

wherein said control program is arranged for defin- 
ing and executing a uniquely labeled time coordi- 
nated motion instruction for communicating infor- 
mation among said plurality of controllers; and 
wherein said controllers are arranged for synchro- 
nized execution of like labeled time coordinated mo- 
tion instructions such that said instructions execute 
in such a way that they jointly begin at a first time, 
follow a common relative velocity profile, and jointly 
end at a second time. 

19. The system according to claim 18, 

wherein said motion instruction source is local to 
said controller. 

20. The system according to claim 18 or 19, 
wherein said motion instruction source is remote 
from said controller 

21 . The system according to one of claims 1 8 to 20 fur- 
ther comprising: 



an associated clock for each controller that pro- 
duces timing information based on a temporal 
reference frame; and 

a system for supplying a synchronization signal 
5 to said controllers that periodically aligns the 

temporal reference frames of said clocks; 
said controllers being arranged for using said 
clocks to control said associated motion sys- 
tems such that said attached robots controlled 
10 by said motion systems operate with clock- 

alignment. 

22. The system according to claim 21 , 

wherein said clocks are hardwired to said control- 
's lers. 

23. The system according to claim 21 or 22, 
wherein said clocks are connected to said control- 
lers via phase locking means, said phase locking 

20 means comprising a serial synchronizing connec- 
tion and/or an Ethernet connection. 

24. The system according to one of claims 8 to 23, com- 
prising an associated clock for each controller that 

25 produces timing information based on a temporal 
reference frame; and a system for supplying a syn- 
chronization signal to said controllers that periodi- 
cally aligns the temporal reference frames of said 
clocks; said controllers being arranged for using 

30 said clocks to control said associated motion sys- 
tems such that said attached robots controlled by 
said motion systems operate with clock-alignment. 

25. A system for controlling a plurality of robots, said 
35 system comprising: 

a plurality of controllers, each having an asso- 
ciated motion system controlling attached ro- 
bots; 

40 at least one of said controllers having at least 

one motion instruction source; 
a computer network over which said controllers 
communicate; 

at least one first controller of said plurality of 
45 controllers having a position sending system for 

sending a commanded position of said at- 
tached robots over said network; 
at least one second controller of said plurality 
of controllers having a position receiving sys- 
50 tern for receiving said commanded position 

over said network from at least one of said first 
controllers; 

said second controller arranged for defining at 
least one first robot reference frame with a fixed 
55 position relative to some point on said robot at- 

tached to said first controller (independent ref- 
erence frame) and at least one second robot 
reference frame with a fixed position relative to 
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some point on said robots attached to said sec- 
ond controller; 

said second controller arranged for maintaining 
a certain spatial transformation relationship 
(dependency relationship) between said sec- 5 
ond robot reference frame (dependent refer- 
ence frame) and said independent reference 
frame; 

said relationship specified by said motion in- 
struction source of said second controller. io 

26. The system according to claim 25, 

wherein said spatial relationship is a Cartesian 
transformation relationship. 

15 

27. The system according to claim 25 or 26, 
wherein a teaching system of said second controller 
is arranged for recording taught positions defined 
relative to an independent reference frame for later 
use. 20 

28. The system according to one of claims 25 to 27, 
wherein said motion instruction source of said sec- 
ond controller is arranged for creating said depend- 
ency relationship between a second robot refer- 25 
ence frame and said independent reference frame. 

29. The system according to one of claims 25 to 28, 
wherein said motion instruction source of said sec- 
ond controller is arranged for issuing a relative mo- 30 
tion instruction such that said dependency relation- 
ship of said second controller is a motion of said 
dependent reference frame defined relative to said 
independent reference frame. 

35 

30. The system according to one of claims 25 to 29, 
wherein said second controller is arranged for main- 
taining said transformation dependency relation- 
ship between said dependent reference frame and 
said independent reference frame while there is no 40 
command from any one of said motion instruction 
sources of said second controller and/or when said 
second controller changes from one of said instruc- 
tion sources to another. 

45 

31. A system for controlling a plurality of robots, said 
system comprising: 

a plurality of controllers, each having an asso- 
ciated motion system controlling attached ro- so 
bots; 

at least one of said controllers having at least 
one motion instruction source; 
a computer network over which said controllers 
communicate; 55 
at least one first controller of said plurality of 
controllers having a position sending system for 
sending a commanded position of said at- 



tached robot over said network; 
at least one second controller of said plurality 
of controllers having a position receiving sys- 
tem for receiving said commanded position 
over said network from at least one of said first 
controllers; 

said second controller arranged for defining at 
least one first robot reference frame with a fixed 
position relative to some point on said robot at- 
tached to said first controller (independent ref- 
erence frame) and at least one second robot 
reference frame with a fixed position relative to 
some point on said robot attached to said sec- 
ond controller; 

said second controller arranged for maintaining 
a certain spatial transformation relationship 
(dependency relationship) between said sec- 
ond robot reference frame (dependent refer- 
ence frame) and said independent reference 
frame; 

said relationship specified by said motion in- 
struction source of said second controller; 
said system further comprising: 

an associated clock for each controller that 
produces timing information based on a 
temporal reference frame; and 
a system for supplying a synchronization 
signal to said controllers that periodically 
aligns the temporal reference frames of 
said clocks; 

said controllers being arranged for using 
said clocks to control said associated mo- 
tion systems such that said attached robots 
controlled by said motion systems operate 
with clock-alignment. 

32. The system according to claim 31 , 

wherein a teaching system of said second controller 
is arranged for recording taught positions defined 
relative to an independent reference frame for later 
use. 

33. The system according to claim 31 or 32, 
wherein said motion instruction source of said sec- 
ond controller is arranged for creating said depend- 
ency relationship between a second robot refer- 
ence frame and said independent reference frame. 

34. The system according to one of claims 31 to 33, 
wherein said motion instruction source of said sec- 
ond controller is arranged for issuing a relative mo- 
tion instruction such that said dependency relation- 
ship of said second controller is a motion of said 
dependent reference frame defined relative to said 
independent reference frame. 

35. The system according to one of claims 31 to 34, 
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wherein said second controller is arranged for main- 
taining said transformation dependency relation- 
ship between said dependent reference frame and 
said independent reference frame while there is no 
command from any one of said motion instruction 
sources of said second controller and/or when said 
second controller changes from one of said instruc- 
tion sources to another. 
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Interpolate Correction transform based on 
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and send update 
acknowledge message to 
publisher 



5C5 



1 



Request latest independent 
frame information message 
from MSP, manual motion 
or planner 

I ~ 



Wait with specified timeout for 
update message from desired 
faceplate; put any other 
message in other wait Q 



If update within timeout, 
update the remote faceplate 
data in faceplate data table 



Calculate current faceplate 
position using: latest velocity 
update x time since last update 
+ latest update position 



Calculate requested 
independent frame state 
from update faceplate state 



Return requested frame state 
update to requestor (planner, 
manual motion , or MSP) 



Fig. 5b 
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Siart Motion Planner 



Wait next Control 
Program Motion 
Instruction 




No. same frame and tool as 
previous motion 



Calculate parameters for next motion. 
If next motion is to be blended, define a new final 
motion, place it back in the wait Q and plan the 
current motion as a blend motion. 




Fig. 6a 
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Yes. new frame 



No, same frame as 
previous motion 



If remote frame, send new frame 
info to IFSS and request a 
subscription IO 



11 ■ 



Request and Wait fa frame 
state update from IFSS 



Estimate Ind Frame at start time 



Reset Start State in new frame and tod using: 
StartPos = 

PlanlndFrame-1:CurFaceplatePos:PlanTool: 



i 



/ 

S3 



Fig. 6b 
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Calculate next interpolated position of current 
tod in current frame 



Send current frame, current tod. current 
position, current velocity in frame, and pe cent of 
motion to Motion State Publisher ♦ subscription 
10 for any remote frames 




St 



No, wait fa next tick 



Yes. go get another from Q 



Fig. 7 
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Move Pan InG ripper to Pi World @ World 



RITimeLine: 




Subscribe 



4 a 



Periodic stale R1 - R2 and | 
periodic slate response R2 - Rl i 
I 

* 



Unsubscribe 



Mov Torch to PtPart @ ParllnGripper 



Mov Torch to PZWortd @ World 



(Rendezvous) (Stationary relative (DeoarO 
j to pan) I 



R2TimeLine 




PIPart 



POWorld 



IWorld 



P2World 



Fig, 8 
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